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REAL-TIME MONITORING, ANALYSIS, 
AND FORECASTING OF TRUNK GROUP USAGE 

CROSS-REFERENCE TO RELATED APPLICATION 

[0001] This present application claims priority to copending U.S. provisional 

application having ser. no. 60/462,991, which was filed on April 15, 2003 and is 
entirely incorporated herein by reference. 

TECHNICAL FIELD 

[0002] The present disclosure is generally related to efficient monitoring of 

telecommunications trunk group usage to allow analysis of the usage and to generate 
forecasts of the future demand for trunking capacity. 



BACKGROUND 

[0003] As known in the art, trunks and trunk groups are used to connect telephone 

company central offices (COs). Historically, analog frequency-division multiplexed 
(FDM) trunks were replaced in the 1960s and 1970s with digital time-division 
multiplexed (TDM) trunks using T-carrier and E-carrier technologies of various 
capacities such as the twenty-four 56/64 kbps digital speed 0 (DS0) channels in a Tl 
or the thirty-two DS0 channels in an EL Today, the Plesiochronous Digital Hierarchy 
(PDH) of T-carrier and E-carrier for trunks usually has been replaced by the 
Synchronous Digital Hierarchy (SDH) as implemented in SONET (Synchronous 
Optical Network) rings on optical fiber carriers (OC). Unlike the higher T-carrier 
multiplexing levels such as T3, which carries 28 DSls with 24 DSOs each for a total 
of 28 X 24 = 672 DSOs, the SDH technologies such as OC-1 carry the DSOs in a 
floating frame to allow easier dropping and insertion of DS0 channels despite slight 
timing differences of the network multiplexers. 

[0004] While optical fiber technology as well as wavelength division multiplexing 

(WDM), which essentially frequency-division multiplexes multiple optical signals on 
a single fiber, has increased the bandwidth available relative to the costs of 
implementing, installing, and supporting a given bandwidth, capacity planning and 
management for large scale networks still can be valuable in the efficient economic 
use of telecommunication network assets and facilities. Generally, the public 
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switched telephone network (PSTN) was developed to handle circuit-switched voice 
telephone calls. Local loops or access lines provide analog plain old telephone service 
(POTS) to residences and business. Generally, the loops or subscriber lines are 
connected to switches or to multiplexers known as subscriber loop carrier (SLC) 
systems, digital loop carrier (DLC) systems, or remote terminals that generally 
concentrate the traffic of multiple access lines into a multiplexed line that connects to 
a switch. 

[0005] To establish connections through the telecommunications network, customers 

usually enter a destination address commonly known as a phone number that generally 
is interpreted by the originating switch to which the customer's access line is 
connected. In modern networks, the originating switch usually communicates 
Signaling System 7 (SS7) messages to various databases and other switches to 
establish a connection through the network from the calling address (essentially the 
phone number of the call originator) to the called address (essentially the destination 
phone number). The switches and SS7 databases establish a route for the call over the 
trunks between switches using network elements such as, but not limited to, 
transmission facilities, multiplexers, and possibly intermediate switches. 

[0006] While the PSTN was initially designed to handle voice telephone calls, the 

network now is used for many other types of communications. Some of the traffic 
engineering concepts developed for circuit-switched voice telephone call capacity 
planning also are relevant for properly designing and sizing the more complex 
network of today. In particular, the load or utilization level of connection-oriented 
systems that use fixed quantities of bandwidth (or multiples of a base fixed quantity of 
bandwidth) for each connection can be measured by multiplying the time for each 
connection by the number of base bandwidth units utilized in the connection. For 
instance, an Integrated Services Digital Network (ISDN) Basic Rate Interface (BRI) 
connection using two 64 Kbps DS0 B-chartnels to an Internet Service Provider (ISP) 
for one minute represents 2 DS0 channels X 60 seconds or 120 connection-seconds or 
call-seconds, when the base unit of bandwidth for a call is one DS0 channel. The 
connection-seconds or call-seconds unit of network load usage/utilization (as well as 
network load capacity) is a useful metric or measurement that has been used in 
telephone network traffic engineering when the network was all analog with analog 
switches and trunks, and that is still used today when the switches and trunks 
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primarily are based on establishing digital connections at multiples of the DS0 56/64 
kbps bit rate. 

[0007] Although the PSTN generally standardized 3.1 KHz connections through 

analog switches and over analog trunks as well as 56/64 kbps ITU-T G.71 1 ja-law or 
A-law pulse code modulation (PCM) connections through digital switches and over 
digital trunks to handle voice telephone calls, the call-seconds metric can be used as a 
measurement for DSO-based data communications as well. In addition, other base 
bandwidth units than a DS0 or a 3.1 KHz audio channel may be used as well with the 
call-seconds metric. For instance, modern voice encoding algorithms such as ITU-T 
G.726 adaptive differential pulse code modulation (ADPCM) and ITU-T G.729 code 
excited linear prediction (CELP) support 32 kbps and 8 kbps voice encoding 
respectively. The bandwidth of a single 64 kbps channel could be managed at a level 
that allows 2 X 32 kbps ADPCM calls or 8 X 8 kbps CELP calls over a single DS0. 
For 32 kbps ADPCM calls, the 64 kbps DS0 has a capacity of 2 calls X 3,600 seconds 
/ hour = 7,200 ADPCM call-seconds / hour. For 8 kbps CELP calls, the 64 kbps DS0 
has a capacity of 8 calls X 3,600 seconds / hour = 28,800 CELP call-seconds / hour. 
Furthermore, the call-seconds or connection-seconds metric may be relevant for other 
connection-oriented communications (such as, but not limited to, the logical channels 
of X.25 or the virtual circuits of frame relay and asynchronous transfer mode (ATM)) 
that are utilized in constant bit rate (CBR) applications that happen to communicate at 
some multiple of a base bit rate. Other load metrics or measurements than call- 
seconds likely would be used for measuring connectionless communications or 
connection-oriented communications in which the bandwidth utilized for each 
connection generally is completely variable. Thus, although the call-second metric 
normally is applied to circuit-switched calls through the PSTN, the metric is useful for 
other types of communications as well. 

[0008] Several queuing theory performance models were developed by Danish 

mathematician A. K. Erlang, and are used in telecommunications network traffic 
engineering. Also, instead of using call-seconds as the units for work load, one skilled 
in the art often may use units of hundreds of call-seconds or centum call-seconds 
(CCS), or even the unit of Erlangs to ease the representation of workload numbers. 
As one skilled in the art will be aware, a centum call-second (CCS) is 1 call or 
connection occupying a channel (or server) for 100 seconds. In addition, one skilled 
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in the art will be aware that an Erlang is one call or connection occupying a channel 
(or server) for one hour or 1 Erlang = 36 CCS. 

[0009] In the past, network traffic engineers have collected data on trunk group 

utilization and load levels to plan future network capital improvements and efficiently 
deploy networking equipment to meet the desired service level requirements. Often 
this utilization and load information was collected from network switches and other 
active network elements to generate reports that network engineers would manually 
sift through to help in planning future changes and reconfigurations of the network. 
The large volume of performance data generated by the network monitoring together 
with complexities of the computations often led to an estimation of network load 
based on a determination of a busy hour statistic, which generally was calculated with 
a frequency of about once per year. Network planning and forecasting based on such 
a yearly busy hour determination likely would diverge significantly from actual 
network usage and utilization over the course of a year in today's dynamically 
changing telecommunications environment. Thus, a system that automates many of" 
these network monitoring, performance analysis, and capacity planning/forecasting 
tasks could improve economic efficiency by more accurately matching network 
equipment deployments to meet the service level requirements at a particular network 
load level. Such a system would reduce the underutilized network assets that are 
deployed, while increasing the deployment of network assets in areas where the 
service level goals are not being met or are just marginally being met. 

U.S. Patent No. 6,01 1,838 entitled "Process and System for Dynamically 
Measuring Switch Traffic" and issued to Stephen Todd Cox on January 4, 2000 as 
well as U.S. Patent No. 6,449,350 entitled "Processes and Systems for Dynamically 
Measuring Switch Traffic" and issued to Stephen Todd Cox on September 10, 2002 
describe some of the traffic engineering concepts related to switch elements and 
modules. U.S. Patent No. 6,01 1,838 and U.S. Patent No. 6,449,350 are each 
incorporated by reference in their entireties herein. However, neither of these two 
patents addresses the traffic engineering issues for trunking and trunk groups. 

[0010] Thus, a heretofore unaddressed need exists in the industry to address the 

aforementioned deficiencies and inadequacies. 
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SUMMARY 

[001 1] Embodiments, among others, of the present disclosure include systems and 

methods for managing deployed trunk circuit capacity in a telecommunications 
network. 

[0012] Briefly described, in architecture, embodiments of the method among others, 

are implemented as follows. Trunks are monitored to collect usage data, which is then 
analyzed including the computation of time-moving averages. Based on the analyzed 
data, forecasts of expected trunking capacity requirements are prepared. The forecasts 
are entered and displayed through a graphical user interface (GUI). Network 
equipment and facilities can be provisioned to support the forecast, and connection 
routing can be optimized to use the provisioned equipment and facilities. 

[0013] Other systems, methods, features, and advantages of the present disclosure will 

be or become apparent to one with skill in the art upon examination of the following 
drawings and detailed description. It is intended that all such additional systems, 
methods, features, and advantages be included within this description and be within 
the scope of the present disclosure. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] Many aspects of the disclosure can be better understood with reference to the 

following drawings. The components in the drawings are not necessarily to scale, 
emphasis instead being placed upon clearly illustrating the principles of the present 
disclosure. Moreover, in the drawings, like reference numerals designate 
corresponding parts throughout the several views. 

[0015] FIG. 1 is a diagram of various non-limiting types of access lines that can 

utilize some of the bear capabilities on trunk groups between switches. 
[0016] FIG. 2 is a diagram of an example telecommunications network with switches, 

trunks, and access lines or loops. 
[0017] FIG. 3 shows some of the functions in a data warehouse and analytical 

processing system for trunking and routing. 
[001 8] FIG. 4 is detailed diagram of a non-data warehouse example system for 

trunking and routing decision making. 
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[0019] FIG. 5 is detailed diagram of a data warehouse example system that 

consolidates relevant information to make advanced analytical business decisions on 
trunking and routing network deployments and configurations. 

[0020] FIG. 6 is diagram of a graphical user interface (GUI) that displays some 

performance information and metrics on trunk group traffic usage. 

[0021] FIG. 7 is a performance usage graph comparing over time the trunks in service 

versus the number of trunks requested to support the call or connection volume over 
the trunks. 

[0022] FIG. 8 is diagram of a graphical user interface (GUI) that displays some of the 

forecasting options that are available to a network planner or designer to efficiently 
allocate enough trunk resources to meet the demanded service level without 
needlessly deploying costly over capacity. 

DETAILED DESCRIPTION 

[0023] Reference is now made in detail to the description of the embodiments as 

illustrated in the drawings. While several embodiments are described in connection 
with these drawings, there is no intent to limit the embodiment or embodiments 
disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, 
and equivalents. 

[0024] FIG. 1 shows two circuit switches 103 and 105 interconnected by one or more 

trunk groups of various bearer capabilities. In particular, the following circuit- 
switched bearer capabilities often are found in telecommunications networks: 64 kbps 
unrestricted 11 1, 64 kbps restricted 1 12, 56 kbps unrestricted 113, 3.1 KHz audio 114, 
and speech 115. Generally, these bearer capabilities can be used to mark or identify 
the capabilities of different types of historical trunk groups in the telephone network. 
As one skilled in the art will be aware, the 64 kbps unrestricted 111 bearer capability 
supports 64 kbps using Binary 8-bit Zero Suppression (B8ZS) to maintain pulse 
density or one's density for Tl transmission equipment synchronization clocking, 
while the 64 kbps restricted 112 bearer capability supports 64 kbps, but requires the 
customer devices or data to be restricted to meet the one's density or pulse density 
requirements to maintain Tl repeater synchronization clocking. The 56 kbps 
unrestricted 113 bearer capability will work over trunk groups that do not support 
B8ZS and clear channel 64 kbps capability. The 3.1 KHz audio 1 14 bearer capability 



7 



TKHR Docket No. 190250-1220 
BLS Docket No. 030156 

can be used to identify trunk groups supporting the transmission of 3.1 KHz audio 
channels. If any older FDM analog trunks still exist in some telecommunications 
network, these trunks could be marked with the capability of bearing 3.1 KHz audio. 
In addition, the speech 115 bearer capability can be used to mark or identify trunk 
groups that are only designed for carrying human voice. For example, time-assigned 
speech interpolation (TASI) was a technology used on older transatlantic cables to 
allow 30 voice phone calls over a Tl instead of the normal limit of 24. TASI worked 
by taking advantage of the normally half-duplex nature of human voice conversations. 
Trunk groups using such half-duplex communication might not be able to carry analog 
modem or fax communications that expect a full-duplex 3.1 KHz audio channel, 
which may be simulated through p.-law or A-law PCM at 56/64 kbps. Furthermore, a 
trunk group could be installed that supports other types of voice compression such as 
G.726 32 kbps ADPCM or G.729 8 kbps CELP. While the channels on such a trunk 
group take advantage of the particular nature of human voice communications to save 
on bandwidth, such channels might not be capable of handling analog modem or fax 
communications that expect a full-duplex 3.1 KHz audio connection, which may be 
simulated through ^i-law or A-law PCM at 56/64 kbps. 
[0025] While most modern telecommunications switches support the bearer 

capabilities of 64 kbps unrestricted 1 1 1, 64 kbps restricted 112, 56 kbps unrestricted 
113, 3.1 KHz audio 1 14, and speech 115, today most trunk groups in major networks 
utilize 64 kbps clear channel DSOs. A 64 kbps clear channel generally will support or 
simulate the capabilities of the other possible requested bearer capabilities. However, 
the call routing for the switches generally has to be configured based on routing calls 
of particular bearer capabilities over trunk groups that will either natively support or 
transparently simulate the bearer capability. Thus, when programming the switch 
translations or configuring the switches, the switch administrators often must set up 
the call routing for the switches based on these different bearer capabilities. However, 
many database systems only keep track of whether a trunk group supports circuit- 
switched data (CSD) 121 or circuit-switched voice (CSV) 122. Thus, the individual 
bearer capabilities of 64 kbps unrestricted 1 1 1, 64 kbps restricted 112, and 56 kbps 
unrestricted 1 13 are often grouped together as CSD, while the individual bearer 
capabilities of 3.1 KHz audio 1 14 and speech 115 are often grouped together as CSV. 
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[0026] In addition to the trunks and trunk groups between switches, circuit switches 

103 and 105 are shown supporting various non-limiting types of access lines and 
devices. In particular, circuit switch 103 is shown connected to a private branch 
exchange (PBX) 131 over a Tl/El line with bit-robbed channel associated signaling 
(CAS) 132, connected to circuit-switched data equipment 133 over an ISDN Primary 
Rate Interface (PRI) 134, connected to an ISDN Basic Rate Interface (BRI) device 135 
over an ISDN BRI 136, connected to a switched 56/64 kbps data service unit (DSU) 
137 over a switched 56/64 kbps access line 138, and connected to a POTS device 139 
over a POTS loop 140. Also, circuit switch 105 is shown connected to a private 
branch exchange (PBX) 151 over a Tl/El line with bit-robbed channel associated 
signaling (CAS) 152, connected to circuit-switched data equipment 153 over an ISDN 
Primary Rate Interface (PRI) 154, connected to an ISDN Basic Rate Interface (BRI) 
device 155 over an ISDN BRI 156, connected to a switched 56/64 kbps data service 
unit (DSU) 157 over a switched 56/64 kbps access line 158, and connected to a POTS 
device 159 over a POTS loop 160. 

[0027] The various types of access devices generally utilize various signaling 

techniques to originate connections or calls through the network. If the access line 
associated with the called address or destination phone number is a loop off of the 
same switch as the access line that is originating the call, then the call generally is 
completed using the switching fabric within the single switch that is the origination 
and destination of the call. On the other hand, if the access line associated with the 
called address or destination phone number is connected to a different switch than the 
switch that supports the access line originating the call, then the call or connection 
generally is carried over one or more trunk groups between switches and may 
transverse some intervening switches as well. 

[0028] Some of the types of access lines have less sophisticated signaling methods for 

initiating calls or connections, and normally these less sophisticated types of signaling 
methods cannot request specific bearer capabilities for the call from the network. As a 
non-limiting example, a POTS device 139 or 159 (such as, but not limited to, an 
analog phone) can signal the destination address using either rotary pulse dialing or 
dual-tone multi-frequency (DTMF) touch tone dialing. However, a POTS phone 
cannot specify the bearer capability for a particular call or connection. Thus, the 
switches generally automatically specify calls from and to POTS loop devices with 
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bearer capabilities of 3.1 KHz audio 1 14 and/or speech 115. Also, switched 56/64 
DSUs 137 and 157 sometimes support a DTMF dialing procedure to signal the 
network to establish a 56 kbps or 64 kbps connection to the destination phone number 
specified in the DTMF dialing. Still, switched 56 and switched 64 DSUs generally do 
not have a signaling mechanism for specifying the bearer capability of particular calls 
or connections. As a result, the switches generally automatically specify calls from 
and to switched 56 devices with bearer capabilities of 56 kbps unrestricted 113 and 
specify calls from and to switched 64 devices with bearer capabilities of 64 kbps 
unrestricted 111 or 64 kbps restricted 1 12. In contrast, ISDN PRI and BRI devices 
have a D-channel for sending digital messages that not only specify the destination 
address or called party number but also specify the requested bearer capability through 
the network. Therefore, ISDN BRI and PRI devices, with the proper switch 
translations, can signal the network to establish calls with various capabilities that 
terminate on different types of network access lines. For instance, an ISDN BRI 
device 135 could initiate a 3.1 KHz audio 1 14 or speech 115 call to a POTS device 
139. In addition, the same ISDN BRI device 135 could initiate a 64 kbps unrestricted 
111 call to a switched 64 DSU 137. Although not shown in FIG. 1, devices on ISDN 
access lines often can access packet-switched services as well as circuit-switched 
services. Thus, ISDN devices provide Integrated access to the Services in the Digital 
Network. Based on the particular bearer capabilities supported by various types of 
access lines or loops, the connection or call routing through the network switches and 
over trunk groups is configured to handle the different types of bearer capabilities for 
various destination or called addresses, which are usually more commonly known as 
phone numbers. 

Moving now to FIG. 2, which shows an interconnected network of several 
switches and trunks or trunk groups. While not shown in FIG. 2, trunk groups and 
connection/call routing actually are based on the bearer capabilities and/or connection 
type of CSV or CSD that were described with respect to FIG. 1. For simplicity, FIG. 
2 will be described only with respect to voice telephone calls, but one skilled in the art 
will recognize the application to other types of connection-oriented communications 
such as, but not limited to, CSD. FIG. 2 shows switches 201, 203, 205, and 207 as 
well as tandem switch 209. Switch 201 is connected to POTS phone 211 over access 
loop 212, while switch 203 is connected to POTS phone 213 over access loop 214. 



10 



TKHR Docket No. 190250-1220 
BLS Docket No. 030156 

Also, switch 205 is connected to POTS phone 215 over access loop 216, and switch 
207 is connected to POTS phone 217 over access loop 218. 

[0030] In addition, nine trunk groups 221, 222, 223, 224, 225, 226, 227, 228, and 229 

interconnect some but not all of the pairs of switches. The network of switches does 
not form a complete mesh because there is no direct trunk group connection between 
switch 201 and switch 205. In general, a complete mesh network for 5 switches 
would need direct connections between each pair of switches. Mathematically, the 
number of connections needed for a complete mesh network of 5 switches can be 
computed as the combinations of 5 switches taken 2 at a time (or pairwise). 
Therefore, for a complete mesh network of 5 switches, the total number of trunk 
connections needed would be 5! / [2!(5 -2)!] = 5! / [2! X 3!] = 5 X 4 / 2 = 10. 
However, implementation of such a complete mesh network generally would be 
overly expensive, especially as the number of switches in the network becomes larger. 
Therefore, network designers and planners generally utilize intermediate switches in 
some routes to reduce the number of direct connections needed between each switch. 

[0031] As an example, there is no direct connection between switch 201 and 205. 

Therefore, a phone call from POTS phone 21 1 to POTS phone 215 might transverse 
the following path: access loop 212, switch 201, trunk group 222, tandem switch 209, 
trunk group 227, switch 205, and access loop 216. Tandem switch 209 can be used an 
intermediate switch for connecting the calls between access loops on switch 201 and 
access loops on switch 205. Furthermore, while tandem switch 209 is shown without 
any access loops or lines, the tandem function often can be performed by switches that 
also support subscriber access lines. For instance, a phone call from POTS phone 211 
to POTS phone 215 might transverse the following path: access loop 212, switch 201, 
trunk group 224, switch 207, trunk group 229, switch 205, and access loop 216. In 
such a situation, switch 207 is performing a tandem function in addition to supporting 
subscriber loops. Usually the tandem function involves special software loads and/or 
software configurations on a switch, and sometimes various switch hardware is 
optimized for performing the tandem function in contrast to providing the access loop 
support function. Thus, in large telecommunications networks some switches (such as 
switch 209) may be strictly utilized for performing the tandem function, while other 
switches (such as switches 201, 203, 205, and 207) may be strictly utilized for 
supporting subscriber loop access without supporting any tandem functionality. 
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However, switching equipment often can be configured to support different 
applications such as, but not limited to, the tandem function and the subscriber loop 
support function. 

[0032] While FIG. 2 shows the concept of trunk groups interconnecting switches and 

the concept of tandem switching, one skilled in the art will be aware that actual 
network implementations are somewhat more complex. In modern networks, 
switches are normally interconnected by SONET rings that carry the channels for 
trunk groups. Usually the SONET rings are connected to multiplexers, digital cross- 
connects, or channel banks (not shown in FIG. 2) that drop and insert channels into 
the SONET ring to support the trunk groups between switches that are shown in FIG. 
2. In addition, the network signaling messages between switches to establish and tear 
down connections normally are carried over a packet network known as Signaling 
System No. 1 or SS7. In SS7 terminology, the switches for customer service 
connections are known as service switching points (SSPs), while packet switches used 
to forward SS7 signaling messages are known as signaling transfer points (STPs). 
Databases that provide for intelligent service delivery are known as service control 
points (SCPs). 

[0033] As described previously, although the telephone network developed using 

analog technology with analog space-division switches and analog frequency-division 
multiplexing (FDM) for call trunking, the network generally has evolved to digital 
switches and digital time-division multiplexing (TDM) trunks that support both 
analog access loops (such as POTS lines) as well as digital access loops (such as 
ISDN BRIs). Even with the changes to a digital architecture, the primary technology 
presently used in the PSTN is circuit switching. In the future, various packet 
switching technologies could be used for handling phone calls or other connection- 
oriented services. These statistically-multiplexed packet-switching technologies likely 
would utilize a virtual circuit as opposed to datagram packet switching paradigm to 
offer connection-oriented service because virtual-circuit packet switching is 
connection-oriented, while datagram packet switching is connectionless. In addition, 
traffic measurements based on CCS or Erlangs generally would be based on some 
standardized amount of bandwidth resource allocation (and/or multiples of that 
standard) for each connection, call, or virtual circuit because one of the base units or 
quanta of resource allocation in a call-second or connection-second is a call or 
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connection using up one channel of communication resources to carry the call or 
connection. Completely variable bit rate applications over statistically multiplexed 
packet switching networks generally do not have the same quanta of resource usage or 
the resource usage varies over time for each virtual connection or flow of datagrams. 
Therefore, the CCS and Erlang metrics generally are not applicable to such completely 
variable bit rate applications on statistically multiplexed packet switching networks. 

[0034] FIG. 3 shows one non-limiting embodiment of data warehouse system for 

trunking and routing. In general, data warehousing and On-Line Analytical 
Processing (OLAP) are decision support technologies to facilitate managerial resource 
allocation and cost structure decisions. While data warehousing often utilizes some of 
the concepts of common database technology, the performance requirements and 
demands on data warehousing systems are often quite different from the demands on 
database systems that support operational functions such as on-line transaction 
processing (OLTP) systems that often automate clerical record keeping tasks. In 
contrast, data warehousing systems are designed to help decision makers with tasks 
such as, but not limited to, data aggregation, data filtering, and data selection to 
produce relevant information that allows the decision maker to make better economic 
business decisions on resource allocations. Because of the vast amount of data that 
may be relevant to a decision maker or resource manager, data warehouses normally 
are much larger database systems than OLTP database systems. 

[0035] ' In FIG. 3 trunk usage data from switch 301 is collected by data collector 303. 

This trunk usage information is passed into data warehouse 300 where data analysis 
3 1 1 is performed. Based on the data analysis 311, one or more forecasts of trunk 
group capacity necessary to meet various service level requirements can be produced 
in forecasting 313. In developing forecasts of trunk group capacity necessary to meet 
the demand at a specified level of service, often resource managers perform "what if 
scenario analysis to evaluate potential outcomes of various decision paths and also to 
test how effective particular decisions would be in the event of unexpected changes in 
demand. After making a decision on a forecast, network resources are provisioned to 
meet the forecasted demand at the specified service level. Provisioning 315 normally 
involves configuring and/or deploying transmission facilities and equipment such as, 
but not limited to, digital cross-connect systems (DCS) and/or drop-and-insert 
multiplexers to establish the forecasted number of trunk connections in the trunk 
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groups between various switches. If a trunk group already exists with too much 
excess capacity for the forecasted demand, some network equipment and/or 
transmission facilities may. be removed from that trunk group and used for other needs 
in the network. If a trunk group has too little capacity For the forecasted demand, 
some network equipment and/or transmission facilities may be added to that trunk 
group to meet the service level objectives. 
[0036] Once the trunk groups have been provisioned, connection or call routing 317 is 

performed to establish the rules for routing calls or connections over the trunk groups 
and through the switches based on the destination phone number. The call routing 
information is communicated to the switches 301 and/or the SS7 network (not shown 
in FIG. 3). Often call or connection routes between switches are configured with 
primary and alternate routes. For instance, referring to FIG. 2, trunk group 224 
between switch 201 and switch 207 may be the primary route with 48 circuits for high 
usage (HU) directly between switches 201 and 207. In addition, an alternate route 
may be defined between switches 201 and 207 through trunk group 222, tandem 
switch 209, and trunk group 226 that is used in the event that the primary route is 
completely busy (with all 48 circuits in use) or is out of service. If the alternate route 
through trunk group 222, tandem switch 209, and trunk group 226 between switches 
201 and 207 is the last route in the routing table hierarchy between switch 201 and 
207, then trunk group 222 is considered to be the final trunk group for the route from 
switch 201 through switch 207. Note that the routing from switch 201 to switch 207 
does not have to be the same as the routing from switch 207 to switch 201 . Thus, call 
or connection routing hierarchies and tables are overlaid on top of the provisioned 
trunk groups. 

[0037] When a phone call or connection cannot be completed because the destination 

phone line is busy, telephone call originating customers generally receive audio 
feedback of a slow busy signal of 60 cycles per minute. When a call or connection 
cannot be completed because the network is busy, telephone call originating 
customers generally receive audio feedback of a fast busy signal of 120 cycles per 
minute. The fast busy signal can occur when the telephone switches do not have 
enough resources to switch the call to the destination. Also, a fast busy signal can 
occur when all of the in-service trunk circuits in a route are in use. For example, 
suppose that the primary route from switch 201 to switch 207 over high usage trunk 
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group 224 contains 48 trunk circuits, while an alternate (and final) route from switch 
201 to switch 207 over final trunk group 222, through tandem switch 209, and over 
trunk group 226 contains 24 trunk circuits. In such a situation, if there are currently 
48 + 24 = 72 calls or connections from switch 201 to switch 209, then the 73rd caller 
from switch 201 to switch 207 will receive the network fast busy tone indicating that 
the network does not have enough resources (in this case trunks or trunk circuits) to 
complete the call. 

FIG. 4 shows a previous non-data warehouse system for analyzing trunk group 
usage and forecasting trunk group load levels. Much of the system in FIG. 4 was not 
even automated, and some of the arrows represent data flows of paper records as 
opposed to electronic files. In addition, the relevant data was not consolidated into a 
single system, and some systems with relevant data related to trunk groups were 
completely isolated from the process. Therefore, the inefficiencies in FIG. 4 led to the 
forecasting process generally being performed yearly or at best quarterly. 

As shown in FIG. 4, switch 401 produces trunk usage data that is collected by 
data collection processor (DCP) 403, which forwards information to DAP system 405 
and network data system / traffic information distributor and editor (NDS/TIDE) 421. 
DAP 405 further provided information to traffic data management system — fast 
(TDMSFast) 407. NDS/TIDE 421 provided output to data interchange - common 
transport trunk (DIXC CTTG) 425 and to trunk servicing system (TSS) 427. The 
NDS/TEDE 427 system receives input from the traffic routing database (TRDB) 423 
and from an auto TIDE system 431 that automates some of the traffic information 
distribution and editing functions. TK/FLEX system 429 received information from 
TRDB 423 and TSS 427, and generated an output to the trunk forecasting and 
provisioning system (TFPS) 433. Furthermore, TSS 427 provided input to GTF/VM 
435 which was a general trunk forecasting (GTF) system run on a computer using the 
virtual machine (VM) operating system. GTF/VM 435 interfaced to common 
transport trunk group (CTTG) system 439 and interfaced to the performance 
monitoring and analysis program (PMAP) 437 that collects data and produces metrics 
and reports on network performance. Also, TSS 427 provided input to ODS 441, 
which was overlaid with AODS 443. ODS 441 is the Online Database System, while 
AODS 443 is the Advanced Online Database System. ODS 441 provided electronic 
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access to traffic data from TSS 427 using a character-based user interface. AODS 443 
overlaid a graphical user interface (GUI) on the traffic data information in ODS 441. 

[0040] As shown in FIG. 4, EXACT 41 1 system and CSPS 413 system, which both 

contain relevant information related to trunking and/or routing, were not even in 
communication with the other systems. EXACT 411 is an EXchange Access Control 
Tracking system that processes access service requests (ASRs) for other 
telecommunications carriers such as but not limited to competitive local exchange 
carriers (CLECs) and interexchange carriers (IXCs). Generally these ASRs are 
requests for trunk-side access to the switch as opposed to the loop-side access usually 
sought by network customers. CSPS 413 is the Complex Services Profile System that 
processes service inquiries and requests for complex telecommunication services such 
as but not limited to primary rate interface (PRI) ISDN and metropolitan Ethernet. 

[0041] In addition, TFPS 433 interfaced with TIRKS 451, which is the 

BellCore/Telcordia Trunk Information Record Keeping System that is known in the 
art and that among other things maintains an inventory of trunking facilities in the 
network. RAD 453 is the Report Analyzer for Diversity system, which analyzes 
interoffice trunks to ensure diversity at the facility level by verifying that there is not a 
single point of failure common to a pair of circuits carrying high priority services such 
as but not limited to E91 1 for which a higher reliability is expected. BSTMP 457 is 
BellSouth's Trunk Maintenance Program that helps to identify trunk groups with 
potential maintenance or operational problems that should be investigated further by 
network technicians. 

[0042] Turning now to FIG. 5, which shows a data warehousing system to support 

trunk group traffic capacity planning and connection routing through switches and 
over the trunk groups. In contrast to FIG. 4, data warehouse of network element 
information 500, which also could be called a network information warehouse or 
NIW, consolidates the large quantity of information on network trunks including, but 
not limited to, information on trunk traffic usage, current network configuration, 
planned network changes, and expected changes in demands for connections over the 
network and trunk groups. In FIG. 5 some but not all of the information flows 
between systems are shown with arrows. In particular, switches (such as switch 501) 
generate real-time or at least near real-time traffic data on trunk usage that is collected 
by data collection processor (DCP) 503. This trunk usage data is forwarded from 
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DCP 503 to data warehouse 500. Data warehouse of network element information 
500 generally is a database containing the data for performing online analytical 
processing (OLAP). Data warehouse 500 is integrally connected to advanced routing 
and trunking system (ARTS) 555, which performs the analytical processing of the 
data. 

ARTS 555 communicates with other systems including but not limited to 
EXACT 511, CSPS 513, TIRKS 551, RAD 553, BSTMP 557, CPG server 561, 
BONIS 563, and user terminal(s) 565. In addition, data warehouse 500 may 
communicate with a system for PMAP and studies 537, may generate reports 567, and 
may interact with user terminal(s) 565. The EXACT 511 system is an EXchange 
Access Control Tracking system that processes access service requests (ASRs) for 
other telecommunications carriers such as but not limited to competitive local 
exchange carriers (CLECs) and interexchange carriers (IXCs). Generally these ASRs 
are requests for trunk-side access to the switch as opposed to the loop-side access 
usually sought by network customers. In FIG. 5, the ASRs in EXACT 511 are used to 
more accurately forecast trunk group requirements as an input into ARTS 555. CSPS 
513 is the Complex Services Profile System that processes service inquiries and 
requests for complex telecommunication services such as but not limited to primary 
rate interface (PRE) ISDN and metropolitan Ethernet. TIRKS 551 is the 
BellCore/Telcordia Trunk Information Record Keeping System that is known in the 
art and that among other things maintains an inventory of trunking facilities in the 
network. RAD 553 is the Report Analyzer for Diversity system, which analyzes 
interoffice trunks to ensure diversity at the facility level by verifying that there is not a 
single point of failure common to a pair of circuits carrying high priority services such 
as but not limited to E91 1 for which a higher reliability is expected. BSTMP 557 is 
Bell South' s Trunk Maintenance Program that helps to identify trunk groups with 
potential maintenance or operational problems that should be investigated further by 
network technicians. CPG server 561 is a server for the Complex Provisioning Group 
that processes complex trunk orders based on the information from ARTS 555. 
BONIS 563 is BellSouth's Online NPA/NXX Information System that handles 
number plan area (NPA) and NXX exchange information. In addition, the LERG 
system is the Local Exchange Routing Guide that provides NPA/NXX assignment 
information for the North American Numbering Plan (NANP). PMAP 537 is the 
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Performance Monitoring and Analysis Program that collects data and produces 
metrics and reports on network performance. 

[0044] FIG. 6 shows a graphical user interface (GUI) screen that displays some of the 

performance data and metrics for a trunk group. Normally in large networks, trunk 
groups are assigned a global identifier (ID) such as a trunk group serial number 
(TGSN) that usually uniquely identifies the trunk group within that network. Thus, 
displaying performance data on a trunk group normally involves selecting the trunk 
group by specifying the global ID or TGSN. In addition, trunk groups connect two 
switches in switching offices that also usually are associated with identifiers in large 
networks. As one skilled in the art will be aware, the Common Language Location 
Identifier (CLLI) code is often used in large carrier networks to specify central office 
(CO) switches. Because trunk groups connect two switches, the two ends of the trunk 
group often are identified as office A and office Z for reference purposes. 
Furthermore, in addition to a global ID or TGSN within the network, normally each 
switch has a local identifier for a trunk group. 

[0045] As shown in FIG. 6, the GUI has radio buttons to allow the user to select a 

view of the current real-time or near real-time trunk group usage as of the current day 
(i.e., today) or to select historical views of previous trunk group usage based on 
starting and ending dates and times. In the preferred embodiment, the trunk group 
usage data is displayed for 30 minute reporting intervals, although other embodiments 
could have different reporting intervals. The scroll bars and arrows allow the GUI 
user to scroll through the trunk group usage data for various time periods. The GUI in 
FIG. 6 shows tables of trunk group usage for both the A-side switch or office as well 
as the Z-side switch or office. 

[0046] In the A-side table or office A table, the first entry row shows that the data on 

1/1/04 at a time of 12:00 had a peg count (PC) in of 382 and a peg count (PC) out of 
984. Peg count is a historical term that relates back to the time when trunks were 
connected to pegs on the switches. Essentially, the peg count is the number of phone 
calls or connections made over the trunk during the period with "PC In" being the 
number of inbound connections and "PC Out" being the number of outbound 
connections. Overflow (OVFL) is the number of calls or connections that had to 
overflow to alternate trunk groups because a trunk group higher in the routing priority 
could not handle the call. Overflow percentage (% OVFL) is the number of overflows 
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divided by the peg count out (PC Out). Hold time is the average hold time for 
inbound and outbound calls or connections as computed by the equation of: Hold time 
= Usage (in CCS) X 100 / (PC In + PC Out - OVFL). As an example calculation for 
the 12:00 time period, 2860 CCS X (100 call-seconds/CCS) / (382 calls + 984 calls - 
0 calls) = 209 seconds, which is the average hold time for the calls or connections. 
Usage is the load or volume in centum call-seconds (CCS) on the trunk group for both 
inbound and outbound calls. MAINT is the total time in seconds that the trunk group 
is used for maintenance, while NMB or Number Made Busy is the number of trunks 
that are out of service for maintenance, which is equal to MAINT / 36 because a 
single trunk can support 3600 call-seconds or 36 centum call-seconds in one hour. 
[0047] The Z-side table or office Z table has similar information on the trunk group as 

the information contained in the A-side or office A table. However, for the Z-side 
table the peg count directions are reversed relative to the A-side table. For example, 
on 1/1/04 at 12:00 the A-side table lists PC In of 382 and a PC Out of 984, while the 
Z-side table at the same time lists PC In of 984 and a PC Out of 382. Generally, the 
A-side and Z-side call or connection statistics should be consistent unless there has 
been some mistake or error in the data collected from one or both of the A and Z 
offices or switches. 

[0048] In addition to displaying the trunk group statistics in a graphical user interface, 

FIG. 6 also displays a computed busy hour and the connection volume or load during 
that busy hour. Because the data warehouse 500 contains the consolidated 
information to make busy hour calculations much more frequently than the 
approximate yearly busy hour determination of previous systems, the preferred 
embodiment of the present invention calculates the daily busy hour on at least a 
weekly basis. The Daily Busy Hour for each trunk group is determined (weekly) by 
selecting the highest busy hour Average Offered Load for the group from the busy 
hour averages calculated based upon a rolling 30 day period. Generally, all valid 
measurements are used in these calculations except for measurements that are flagged 
for exclusion. This Daily Busy Hour is determined by using the valid data (which 
excludes data flagged as being unrepresentative) for each half-hour increment (48 
half-hours in a 24 hour day) of each of the last 30 days (matrix 48 X 30) to calculate 
the Average Offered Load for the trunk group. The Daily Busy Hour for the trunk 
group is selected as starting at the half-hour (from 48 points of data) with the highest 
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Average Offered Load. This Daily Busy Hour then is used for the next seven days, 
when running daily blocking reports. 

In addition to the Daily Busy Hour, the data warehouse 500 is used with ARTS 
555 to compute a control hour for a cluster of network switches and trunk groups. A 
cluster is a community of interest in which there is some locality of connections or 
calling patterns. Instead of just optimizing trunk sizing based on the busy hour for 
particular trunk groups, the control hour for a group of switches determines essentially 
the busiest time for that group of switches, which will not necessarily be the same as 
the busy hours for the individual trunk groups between the switches. The grouping of 
switches into clusters of communities of interest allows more efficient network trunk 
group resource forecasting and deployments that are based on a computation of a 
control hour as opposed to the individual busy hours for each trunk group in the 
cluster. In general, a community of interest is identified based on calling patterns that 
indicate some locality of access among the switches in the group or cluster in relation 
to calling patterns that indicate relatively less communications traveling across the 
boundary between the clustered group of switches and other switches not in the 
cluster. 

The Cluster Busy Hour can be calculated through a few operations. First, for 
each trunk group in the cluster, using the matrix of 30 days by 48 half-hour time 
periods, calculate the average Offered Load for each time period, while excluding any 
days that are flagged as unrepresentative from the calculation. Next, the highest 
average Offered Load, from the 48 averages, is the busy hour for the trunk group. For 
each cluster of trunk groups, using the matrix of 30 days by 48 time periods, the trunk 
group Average Offered Loads of each trunk group from the 48 periods are combined 
to form the offered load totals to the cluster in the 48 periods. The period with the 
highest offered load is the Cluster Busy Hour. 

A final trunk group is the last alternate route in a hierarchical routing table 
after the capacity of high-usage trunks has been utilized such that additional 
connections overflow to alternate routes on final trunk groups. For each final trunk 
group, the trunk group busy hour is used as the final busy hour. The control hour for a 
trunk group is either the final busy hour or the cluster busy hour depending on whether 
the trunk group has a higher offered load at the final busy hour or at the cluster busy 
hour. The control hour for a trunk group is selected from the final busy hour and the 
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cluster busy hour based on which one of those hours has the highest offered load to 
the trunk group. 

[0052] In addition, the average offered load is calculated by averaging the 20 highest 

of 30 rolling days of data during the control hour, excluding data that is flagged as 
being unrepresentative. For example, in the preferred embodiment the average 
offered load = [(A-side usage + Z-side usage) / 2] / (1 - % blocking), where % 
blocking = Overflow / PC Out. Averaging the A-side usage and the Z-side usage 
deals with the problem of the A-side data and the Z-side data both being valid, but 
still being inconsistent for some reason. If the usage data from one side of the trunk 
group is not considered to be valid, the averaging of the A-side and Z-side usage data 
should not be used in the calculation. With the use of a rolling 30-day period for 
many of the calculations, the preferred embodiment of the present invention 
essentially continuously generates accurate busy hour and load determinations. This 
information can be used in forecasting arid planning to dynamically change network 
equipment deployments and configurations much more responsively than previous 
systems that computed busy hours and network loads with a frequency of about once 
per year. The rolling 30-day period is a moving average type of computation that will 
react to systematic changes in network usage and demand, but will not be too overly 
sensitive to one abnormal day of network activity. 

[0053] In addition, the GUI in FIG. 6 shows the circuit layout order (CLO) number 

from TERKS with the due date and number of trunks to be added or disconnected. 
Furthermore, FIG. 6 displays the number of trunks in service (TIS) from both the 
switch (SW), if available, as well as from the TERiCS trunk inventory system. 
Sometimes, the switch translations and trunk configurations may not exactly match 
the trunk information contained in TERKS. Also, FIG. 6 shows selection buttons for 
"Show Office Flag", "Show Cluster Data", "Graph", and "Export". The show office 
flag button can be used to reach screens for selecting some trunk usage data as 
unrepresentative and therefore excluded from various computations. The show cluster 
data button displays data relevant to a cluster, while the graph button graphs the trunk 
group load usage versus the trunks in service. As shown in FIG. 7, the trunks 
requested to meet demand or offered load are graphed over time in comparison to the 
trunks in service (TIS). In FIG. 7, the 408 trunks in service are significantly above the 
number of trunks requested during all time periods shown. 
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FIG. 8 shows the graphical user interface (GUI) for one of the forecasting 
screens. In general, the preferred embodiment of the present invention includes five 
different forecasting models. Each of these five models generate a base unadjusted 
forecast and also allow manual adjustments and overrides to generate adjusted 
forecasts. The five models are known as: 1) the historical trunk group CCS growth 
rate model, 2) the theoretical cluster CCS growth rate model, 3) the switch CCS 
growth/de-growth model, 4) the historical network access line (NAL) model, and 5) 
the theoretical network access line (NAL) model. 

The five forecasting models use a monthly busy hour offered load that is 
determined for each half-hour period during the month in which the load data is valid 
and representative. The offered load for each hour is computed as offered load = 
(Usage / [1- ((% blocking) X retrial factor)]. In the preferred embodiment, the retrial 
factor for final trunk groups and overflow trunk groups is 0.55. Next the average 
offered load for each hour is computed by averaging the offered loads in each hour 
across the valid and representative days. The hour with the highest average offered 
load is the busy hour for the month for the trunk group. Using this month busy hour, 
the. average offered load is recalculated for that hour across the highest 20 days that 
are valid. This newly calculated average from the 20 highest valid days at the busy 
hour is the basing value for the month for the trunk group. The basing value is used in 
all the five forecast models. 

The historical CCS growth rate model determines the month with the highest 
average offered load for a trunk group by considering the last 12 rolling months, while 
excluding unrepresentative months that have been flagged. The average offered load 
for this highest month is compared to the average offered load for the same month in 
the previous year to determine the change in CCS load from the previous year to the 
current year. This amount of CCS change is added to the present year to forecast the 
next year's CCS level. 

The theoretical CCS growth rate model determines the month with the highest 
average offered load for a cluster by considering the last 12 rolling months, while 
excluding unrepresentative months that have been flagged. The average offered load 
for this highest month is compared to the average offered load for the same month in 
the previous year to determine the change in CCS load from the previous year to the 
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current year. This amount of CCS change is added to the present year to forecast the 
next year's CCS level. 

The switch CCS growth/de-growth model determines the month with the 
highest average offered load for a switch by considering the last 12 rolling months, 
while excluding unrepresentative months that have been flagged. The average offered 
load for this highest month is compared to the average offered load for the same 
month in the previous year to determine the change in CCS load from the previous 
year to the current year. This amount of CCS change is added to the present year to 
forecast the next year's CCS level. 

The network access line (NAL) forecast computes the forecast CCS as 
Forecasted CCS per year = Base CCS * Projection Ratio * Call Rate * Stimulation 
Factor +/- Stated CCS + Load Transfer CCS. For the NAL forecast, Base CCS = 
highest base month from the last 12 months, excluding flagged unrepresentative 
months. The Projection Ratio can be calculated from the access line forecasts from 
the C A' and/or 'Z' end Office record(s), while the Calling Rate is a stated growth rate 
that is not compounded yearly. Also, the Stimulation Factor is a one time method of 
CCS stimulation in each year, whereas the Stated CCS is a manual adjustment that 
can be added or subtracted by the network planner. The load transfer CCS relates to 
changes in load allocations amongst trunk groups. The NAL historical model uses 
trunk group CCS values for the base CCS. The NAL theoretical model uses cluster 
CCS values for the base CCS. 

In the GUI screen of FIG. 8, some of the forecast settings and a summary 
forecast is displayed. The forecast is for a trunk group with an ID number. The busy 
month in the present year has been determined as February. The DD Variation is a 
measure of the day-to-day variance in trunk group usage, while the peakedness also is 
another parameter describing the statistical distribution of trunk group usage over 
time. The service objective (SVC OBJ) is a parameter selected to designate the 
desired service level that is to be provided by the trunk group. The base is the base 
offered load for the trunk group in CCS. Many of these values are calculated (CALC) 
by the system in the preferred embodiment. In addition, some of the values allow a 
manual override (OVRRD) by a network planner. The working forecast pull down 
box allows the network planner to select one of the five forecasting models and also 
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allows the network planner to specify whether the forecast can be manually adjusted 
by alteration of some model parameters. 

[0061] Furthermore, the GUI screen in FIG. 8 displays the trunks in service (TIS) 

according to the Telcordia TIRKS trunk inventory system, the number of trunks in 
service at the End Of the Year, the number of trunks in service according to switch A, 
and the number of trunks in service according to switch Z. Also, the trunk group (TG) 
start and stop dates are displayed. In addition, the trunk conversion holding time 
(TCHT) is displayed and is the average length of a call on the trunk group. MOD 
TRKS specifies a modulus for adding or removing trunks in those situations where a 
switch or other network equipment has to add capacity in certain multiples such as in 
multiples of 24 DSOs in a Tl. 

[0062] In FIG. 8, several forecast adjustment fields are provided for network planners. 

For example, the call rate % specifies the call hold time percent change, and can be set 
for the years 2002, 2003, 2004, 2005, and 2006. The stimulation factor % is the 
percent that the call volume is to be adjusted from the base year. The total % change 
is the compounded result of the call rate percentage and the stimulation factor 
percentage. Also, FIG. 8 shows the network access line (NAL) calculated projection 
ratios, which can be overridden by manual adjustments using the NAL PRO J RATIO 
OR fields. Because the NAL forecasts are based on the growth in network access 
lines on a switch, the selection of the A switch or the Z switch on each end of the 
trunk group changes the forecast. The switch projection (PROJ.) A-Z field allows a 
network planner to specify which switch is used in NAL forecasts. The Auto Forecast 
(FC) and Saved FC (Forecast) settings allow the network planner to specify the system 
behavior in saving and/or approving new forecasts. 

[0063] Also, FIG. 8 shows various buttons and tabs for selecting and manipulating 

different objects associated with the forecasting task. In particular, selection of the 
summary tab displays the approved forecast as well as transfer and/or adjustment 
summary data. In FIG. 8 the summary tab has been selected, and an example forecast 
summary is displayed. The approved tab displays the 5 year approved forecast by 
month, while the details tab displays the 5 year forecast by month for the 5 forecasting 
models and also displays forecast versions that were adjusted by the network planner. 
The base tab shows the base values that are used in the theoretical and historical 
models. 
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Moreover, in FIG. 8 the NAL Overrides button shows the official network 
access line values as well as any override values for the A and Z offices. The transfer 
and adjust button provides for transfers of trunk groups and manual adjustments of 
trunks or offered loads. The graph button generates a graph of the forecast data. The 
copy working to approved button will allow the user to copy a working forecast into 
the approved forecast area. The reforecast working button will cause a recalculation 
of the forecast using any values that have been changed. The save approved button 
causes the approved forecast to be saved. 

Thus, the forecasting features provide automatic forecasting with multiple 
models for changes in trunk capacity demand. In addition, the forecasting allows 
manual override for expert network planners that have some special knowledge, 
which is not reflected in the system. Also, the forecasting features allow "what if 
scenario analysis to evaluate different trunking configurations and solutions. 

Any process descriptions or blocks in any flow charts should be understood as 
representing modules, segments, or portions of code which include one or more 
executable instructions for implementing specific logical functions or steps in the 
process, and alternate implementations are included within the scope of the preferred 
embodiment of the present disclosure in which functions may be executed out of order 
from that shown or discussed, including substantially concurrently or in reverse order, 
depending on the functionality involved, as would be understood by those reasonably 
skilled in the art of the present disclosure. 

The preferred embodiment of the present invention may be implemented as a 
computer program, which comprises an ordered listing of executable instructions for 
implementing logical functions. As such the preferred embodiment of the present 
invention can be embodied in any computer-readabie medium for use by or in 
connection with an instruction execution system, apparatus, or device, such as a 
computer-based system, processor-containing system, or other system that can fetch 
the instructions from the instruction execution system, apparatus, or device and 
execute the instructions. In the context of this document, a "computer-readable 
medium" can be any means that can contain, store, communicate, propagate, or 
transport the program for use by or in connection with the instruction execution 
system, apparatus, or device. The computer-readable medium can be, for example but 
not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or 
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semiconductor system, apparatus, device, or propagation medium. More specific 
examples (a non-exhaustive list) of the computer-readable medium would include the 
following: an electrical connection (electronic) having one or more wires, a portable 
computer diskette (magnetic), a random access memory (RAM) (electronic), a read- 
only memory (ROM) (electronic), an erasable programmable read-only memory 
(EPROM or Flash memory) (electronic), an optical fiber (optical), and a portable 
compact disc read-only memory (CD-ROM) (optical). Note that the computer- 
readable medium could even be paper or another suitable medium upon which the 
program is printed, as the program can be electronically captured via, for instance, 
optical scanning of the paper or other medium, then compiled, interpreted or 
otherwise processed in a suitable manner if necessary, and then stored in a computer 
memory. 

[0068] Although exemplary embodiments have been shown and described, it will be 

clear to those of ordinary skill in the art that a number of changes, modifications, or 
alterations, as described, may be made. All such changes, modifications, and 
alterations should therefore be seen as within the scope of the disclosure. 

[0069] It should be emphasized that the above-described embodiments of the present 

disclosure, particularly, any "preferred" embodiments, are merely possible examples 
of implementations, merely set forth for a clear understanding of the principles of the 
disclosure. Many variations and modifications may be made to the above-described 
embodiment(s) of the disclosure without departing substantially from the spirit and 
principles herein. All such modifications and variations are intended to be included 
herein within the scope of this disclosure. 
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